PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.083

Internet Message Format | 1988-04-08 | 25.5 KB | [TEXT/ttxt]

Date: Fri 16 Oct 87 19:08:43-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #83

Usenet Mac Digest     Friday, October 16, 1987       Volume 3 : Issue 83

Today's Topics:
     Koala-Vision Demo Program
     Re: Need help making INIT
     Video memory and the Mac II
     Re: Missing deactivate events
     Re: Drawpicture from C - HELP!!
     Re: Excel Meg Limit
     Re: Missing deactivate events
     Re: editing default window size
     Re: Virtual Memory with the Mac OS
     Re: HyperCard stack multi-access
     Thunderscan / Printer problem
     Re: "Pyro"mania/pack your "Suitcase" and go!
     MacDraw or PICT based Clip-Art Recommendations
     Warning: use of "Pyro" and Opcode's MIDIMAC Sequencer (2 messages)
     Protecting your HyperCard stack
     graph packages on the mac
     PICT files
     Mac II fan noise
     Intermail owners take note/Intermail buyers should read

----------------------------------------------------------------------

From: [e-mail] (Greg Corson)
Subject: Koala-Vision Demo Program
Date: 12 Oct 87 18:52:08 GMT
Organization: Math. Dept., Univ. of Notre Dame

I just got a program that is supposed to be a demonstration of how to
read and process data from a KoalaVision video digitizer for the Mac.
Unfortunately I did not get the source, just the compiled program.  The
source was supposed to have been distributed so I was wondering if
anyone out there happens to have a copy of it?

I don't really care what compiler format it's in, although MPW or
Megamax would be preferable (or just send it as text files).

Thanks,
Greg Corson
19141 Summers Drive
South Bend, IN 46637
[phone] (weekdays till 6pm central)
{pur-ee,rutgers,uunet}!iuvax!ndmath!milo

------------------------------

From: [e-mail] (Richard Siegel)
Subject: Re: Need help making INIT
Date: 12 Oct 87 22:11:46 GMT
Organization: THINK Technologies, Inc., Bedford, MA


To create an INIT resource, click on the button labeled "Code Resource"
in the Build And Save As... dialog box; a little dialog will come up and
you can set the resource type (INIT in this case), resource ID,  and
name of your code resource.

The manual doesn't explain this, but the 1.0 Release Supplement does,
and that should have been included along with your package. It will be
incorporated into the manual for the next release.

        --Rich

**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies, Inc).

* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer    *
* Customer Support  | [e-mail]                *
* THINK Technologies, Inc.  (No snappy quote)                       *


------------------------------

From: [e-mail] (Phil Hunt)
Subject: Video memory and the Mac II
Date: 12 Oct 87 18:04:31 GMT
Organization: Digital Equipment Corporation

Hello,

   I was wondering how the Mac II video memory lays out.  In other
words, how do they make old pgms compatible with the new memory map??
I know the video display card now contains memory for the display.  But
that memory is not  counted in the system size memory!!  Is the video
memory now ABOVE mem max for the system???  How does it work....???

   Also, I have found some old pgms (1984-1986) that run IN COLOR. The
old Cricket Graph 1.0 (Yes, 1.0!!) runs on MY MAC II in COLOR,  so does
some card games.  The diamonds and hearts are in color!!!   Is this a
maaping  between othe old Quickdraw 8 color (IE IM II mapping) and the
new CQD???

Phil Hunt


------------------------------

From: [e-mail] (Brian H. Powell)
Subject: Re: Missing deactivate events
Date: 12 Oct 87 21:23:47 GMT
Organization: U. Texas CS Dept., Austin, Texas

     The various Alerts (and ModalDialog, by the way) swallow all the
events that occur while the Alert window is brought up.  That's why
you're missing the deactivate events.  They call HiliteWindow
(indirectly) themselves, and your code for deactivation never gets
called.
     For your code, just do a deactivate (really a fake deactivate, see
below) before you call an Alert.  Dialogs don't cause this problem
because the activate/deactivate events are generated by [Get]NewDialog
and not by ModalDialog.  There are exceptions to this, such as SFGetFile
and SFPutFile. Those guys handle their "own" events, so you need to do a
fake deactivate before calling them.
     You also run into this problem with desk accessories.  Some DAs may
choose to put up an Alert or a standard file dialog.  DAs cause other
problems as well; you can't do a real deactivate because a DA might not
bring up a window.  (It might just install a menu item, for instance.)
This is why I said you should do a "fake" deactivate.

     I had this problem with a TextEdit-based application where I had
globals that pertained to the frontmost (i.e., active) window.  When I
got a deactivate, I stored them in a record pointed to by the refCon
field in the window record.  I couldn't call TEDeactivate for these fake
deactivates since a DA without a window would leave one of my windows in
front that was Hilited, but without an active TE record, so I didn't
have an insertion point or selection range.

     Depending on what you're doing, you might not have to do a
so-called "fake" deactivate.  I had to fake it because I didn't want to
call TEDeactivate unnecessarily.  You might be able to call your real
deactivate routine.  This leads to your next problem...
     One of the features of my TE application was that it didn't hurt to
copy those globals to the refCon record twice (once for a fake
deactivate and once for a real deactivate, in case I got a real one in
the case of a DA.)  In your case, you can only compress once, so you
have to be careful about not recompressing compressed data.  With your
code, you know exactly when you won't be getting the deactivates.  With
DAs, you won't know and you can't find out.  Either don't allow DAs (a
travesty in some peoples' minds) or leave a flag around telling you
whether the data has been compressed or not.  I think you should do the
latter.  Perhaps there are other solutions besides the two that I have
mentioned.

     Good luck.

Brian H. Powell
        UUCP:    ...!uunet!ut-sally!brian
        ARPA:    [e-mail]

   _Work_                     _Not Work_
  Department of Computer Sciences        P.O. Box 5899
  Taylor Hall 2.124                Austin, TX 78763-5899
  The University of Texas at Austin        [phone]
  Austin, TX 78712-1188
  [phone]


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Drawpicture from C - HELP!!
Date: 12 Oct 87 17:09:57 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]> [e-mail] (Joe Gervais)
writes:
>
>    I'm programing in Megmax C (v. 2.0 (?)) and after defining a picture
>and closing it, I can draw it in the original srcrect but if I try to move
>it I don't get anything.  I "believe" I'm doing it correctly, but I just
>don't get anything.  Even just offsetting the srcrect (so as not to change
>size and need scaling) it doesn't work.

This is a common problem with using pictures.

When you open a picture, Quickdraw records the current state ofthe
clipping region in the picture.  When you draw a picture in a rectangle
that is offset from its creation rectangle, Quickdraw offsets the region
as well.

The problem occurs because the default clipping in a new grafPort is the
largest possible rectangle.  Offsetting this rectangle by any amount
causes the coordinates to overflow, thus creating an empty region.  The
empty clipping region prevents anything from being drawn.

The solution is to always set the clipping before or right after calling
OpenPicture.  The general rule of thumb is to call ClipRect with the
same rectangle passed to OpenPicture.


--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: [e-mail]


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Excel Meg Limit
Date: 12 Oct 87 17:36:59 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]> [e-mail] (Cliff Loucks) writes:
>in article <[e-mail]>, [e-mail] (Eric Schlegel) says:
>
>> The latest issue of MacWEEK states that Excel will only work under
>> MF if it is loaded first, presumably so that the code will fall in
>> the first meg.
>
>I just loaded and ran Excel in Juggler with Versaterm and Moire
>loaded first.  I don't have any huge files, but it runs fine
>for me.

The reason it works is that Multifinder allocates memory for
applications starting with the top of memory and working its way down.
This makes it possible for the system heap (which is at the low end of
memory) to expand as needed.

I believe that Excel requires that it be loaded low in memory, and that
Multifinder contains code to accommodate this need.  Since most
application are loaded high, the low end of memory will usually be free,
regardless of the order in which application are run.

--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: [e-mail]


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Missing deactivate events
Date: 12 Oct 87 18:29:39 GMT
Organization: Advanced Technology Group, Apple Computer

The problem will appear with any modal dialog.  In a modal dialog, the
Dialog Manager is in control and receives the events.  If an event is
intended for a dialog window it can do something with it.

If the event is for a non-dialog window, then it throws it away.  The
deactivate event for your window is such an event.  There's really not
much else it can do with such an event.  When the modal dialog goes
away, your application starts receiving events again, and one of the
first it will get is an activate event for its window

In MacApp, we took the approach someone else suggested, which is to keep
track of whether your application's window is already activated, and
ignore the "extra" activate.

If you want, you can catch the deactivate event by passing a filter proc
to the Alert or Modal Dialog call.  In the filter proc, you can call
IsDialogEvent, and if it returns FALSE (not a dialog event) pass the
event to your normal event handling code.

The only problem is that some calls to Alert/Modal Dialog don't come
from your application, which means you can't pass a filter proc.  You
can, however, create a global patch for the Modal Dialog trap which
always passes your filter proc in as a parameter.  (You will have to
call the original filter proc, if it exists.)

I did this once (a while ago), and it seemed to work.  I will try to dig
up the code, but I am not sure if it is around any longer.

--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: [e-mail]


------------------------------

From: [e-mail] (Robert Gardner)
Subject: Re: editing default window size
Date: 12 Oct 87 19:11:51 GMT
Organization: Philips Research Labs, Sunnyvale, California

In article <[e-mail]> [e-mail] (Glenn T. Barry) writes:
>When Guide opens, the default window does not fill the entire screen.

Many early programs used WIND resources to specify new window locations
and sizes, but unfortunately they aren't general-purpose enough to use
effectively with variable-sized monitors. It seems a new resource-type
or redefinition of WIND would be helpful (which GetNewWindow() would
use). For instance, if the window coordinates are negative they could be
interpreted as offsets from the screenbits.bounds. Then, creating a
window that fills the screen with a few pixels of space would use
(0,0,-2,-2) or something. Most programs these days (I suspect) calculate
window sizes on the fly from screenbits.bounds or stuff the old
size/location in the document somewhere. It seems that a nice,
general-purpose, user-modifiable technique is needed now that screen
sizes are not fixed.

Robert Gardner


------------------------------

From: [e-mail] (Stew Rubenstein)
Subject: Re: Virtual Memory with the Mac OS
Date: 12 Oct 87 23:39:18 GMT
Organization: Aiken Computation Lab Harvard, Cambridge, MA

The March APDA draft of "Macintosh Family Hardware Reference" states, on
page 149, that "With either the PMMU or HMMU, one additional wait state
is imposed to do address translation.  Remember that there is one wait
state for the ROM and RAM accesses because of the basic hardware timing
(4 clock cycles for memory access), thereby making ROM and RAM accesses
take a total of 5 clock cycles."

Is it wrong?  Wouldn't be the first time...

Stew Rubenstein
Cambridge Scientific Computing, Inc.
UUCPnet:    seismo!harvard!rubenstein            CompuServe: 76525,421
Internet:   [e-mail]       MCIMail:    CSC

------------------------------

From: [e-mail] (Ed Anson)
Subject: Re: HyperCard stack multi-access
Date: 12 Oct 87 19:17:18 GMT
Organization: Calcomp Display Products Division, Hudson, NH, USA

In article <[e-mail]> [e-mail] (Kerien
Fitzpatrick) writes:
>I was looking through the HyperCard manuals for information about whether or
>not stacks can be viewed by more than one user at a time.

Tough luck.  It looks to me like HyperCard opens every stack read-write,
which means exclusive access.  This leads to several other anomalies,
which annoy me to no end: It's not possible to browse a stack which is
locked or is on a write protected diskette.  Browsing any stack causes
my backup utility to back it up again.

Apparently, this is because of the automatic save feature.  Apple, why
not go ahead and open for browsing, and just warn the user that updates
can't be saved, if the file isn't available for writing?  And why not
provide a HyperTalk command to open read-only (as in Browse)?
--
=====================================================================
   Ed Anson,    Calcomp Display Products Division,    Hudson NH 03051
   [phone],      [e-mail]


------------------------------

From: [e-mail] (H. Moskovitz)
Subject: Thunderscan / Printer problem
Date: 12 Oct 87 15:03:18 GMT
Organization: The Second Door on the Right

I have a Mac SE with the latest Thunderscan hooked up (via the funky
little power port adaptor). I have noticed a problem. Suddenly when I
switch the little a/b box they give you to print and try to print out
documents from Word or try to print pictures from something like
Illustrator, the buffer seems to get corrupted or the handsahling fails
and the printer starts spewing out garbage.

Has anyone out there had a similar problem? What was your solution?

P.S. If I disconnect the printer from the a/b box and plug directly into
the serial port all is fine.
--
-----------------------------------------------------------
        Howard Moskovitz
    AT&T Bell Labs @ Liberty Corner, NJ
        ihnp4!io!howard


------------------------------

From: [e-mail] (Marc Hannah)
Subject: Re: "Pyro"mania/pack your "Suitcase" and go!
Date: 12 Oct 87 23:22:01 GMT
Organization: Stanford University

   I agree that the PYRO/Suitcase package is well worth the price
Software Supply asks. I must say however that it would be easier to keep
PYRO from being pirated if it were also available for ~$15-20 by itself.
I think  SuitCase is in the 'essential' class of software but there are
people who don't realize this yet and still want PYRO. PYRO is the best
screen saver I've seen (next to AutoBlack, which doesn't work on the Mac
II) and it is a shame that more people can't buy it for a lower price.

David Gelphman   [e-mail]


------------------------------

From: [e-mail] (J. Collymore)
Subject: MacDraw or PICT based Clip-Art Recommendations
Date: 12 Oct 87 12:41:51 GMT
Organization: AT&T CSEd/CET, Piscataway, N.J.

Do any of you out there know of or tried any clip-art software that is
in either MacDraw or PICT base format?  I need clip art that has a good
variety of personal, business, and "fun" images in this format so that
it will come out real crisp on a LaserWriter printer.

If you have any recommendations, please e-mail me or post to this
newsgroup.

Thanks a lot.

                        Jim Collymore


------------------------------

From: [e-mail] (J. Collymore)
Subject: Warning: use of "Pyro" and Opcode's MIDIMAC Sequencer
Date: 12 Oct 87 21:06:08 GMT
Organization: AT&T CSEd/CET, Piscataway, N.J.

This is an FYI to those of you who may try to use Opcode Systems MIDIMAC
Sequencer and "Pyro" (screen saver) on your Mac (with a Hard Disk).

I have been in touch with the tech people at Opcode systems regarding
several System crashes I had this Saturday night while I was using their
MIDIMAC  Sequencer 2.54 (4 crashes to be exact, all during "takes."  It
is their recommendation that I NOT use "Software Supply's" Pyro software
while running MIDIMAC seq., particularly on the Mac's Finder 4.1/System
5.5, if I am running off an external Hard Disk. I should expect problems
otherwise.

The irony of this is that about 3 weeks ago I was told by the Opcode
people NOT to use Macsbug (screen saver) with the above configuration
because it would cause system crashes.  However, one of the Opcode techs
at that time told me Pyro should be alright to use on my system setup.

Well, I spent $40+ with Computeware in California to buy "Suitcase"
(which comes with Pyro) and now I find that contrary to what the Opcode
people told me I CAN'T use Pyro.  Forty-dollars down the tubes!

So to save the rest of you this grief, I'm warning you in advance:
DON'T USE PYRO OR MACSBUG with Opcode System's MIDIMAC SEQUENCER!


                        Jim Collymore


------------------------------

From: [e-mail] (Christopher Chow)
Subject: Re: Warning: use of "Pyro" and Opcode's MIDIMAC Sequencer
Date: 13 Oct 87 14:16:00 GMT
Organization: Cornell Theory Center, Cornell University, Ithaca NY

Interesting...can you elaborate a bit more Jim?  I've noticed that
recently I've been getting alot of deadlocks on launch when I use
Sequencer 2.54. I.e., I'd double-click Sequencer and about 50% of the
time the program would freeze upoon launching (apparently finished
loading, but frozen mouse).  I'm using Finder 6.0b<something>, System
5.5, Pyro!, and a Dataframe 20.  I never did suspect it was a
compability problem between Pyro! and Sequencer though.

As an aside, does anyone know why professional music software developers
can't seem to write code that follows Macintosh compability guidelines?
It seems that the first thing to break (sometimes the only thing to
break) is music software.  Take the Mac II as an example - aside from
Midipaint, which was written recently, no sequencer program works on it.
 Even Performer 2.xx, which was just released recently, won't work on a
Mac II.  Meanwhile, the guys at Opcode claim that they've been had since
Apple changed the sound manager on them...at the same time pre-Mac II
Videoworks runs perfectly on a II.

Christopher Chow

------------------------------

From: [e-mail] (Paul Molenaar)
Subject: Protecting your HyperCard stack
Date: 13 Oct 87 09:45:57 GMT
Organization: Nikhef-K, Amsterdam (the Netherlands).

Chuq von Rospach asked a question about the protection of his stacks,
which was replied by someone else describing a method of disabling the
command-key.

I tried this method, but it proved to be flaky if the user persisted in
pressing the cmnd-period keys. The user would even be brought to
script-editing level if pressed enough times (about 3 or 4 times was
enough). Another method was making a button in some stack saying "go to
card..." and "edit script of this card"

I used that script and added some extra features that seem to do the job
correctly. It also provides a reasonably good password protection to
your stack, making it possible to always edit your stack, while others
can only use it. Put in the stack-script (editable in stack-info) and
replace my password with your favourite password.

Here it is:

on idle
if the commandkey is down then deadkey
put the time into card field "time"
pass idle
end idle

on deadkey
answer "Sorry, command-key disabled" with "OK"
end deadkey

on domenu
ask password "Give password"
if it is not 2690438967
then
answer "Sorry, wrong password" with "OK"
else
pass domenu
end if
end domenu

on edit
ask password "Give password"
if it is not 2690438967
then
answer "Sorry, wrong password" with "OK"
else
pass edit
end if
end edit

------------------------------

From: [e-mail] (Janet Wiles)
Subject: graph packages on the mac
Date: 13 Oct 87 08:22:44 GMT
Organization: Dept. of Comp. Science, Uni of Sydney, Australia

I am looking for information on graph packages for the mac. I have been
advised to try cricket graph and would like information from anyone who
has used it,  or suggestions for alternative packages available in
Australia.

My data is generated on a sun workstation and can be formatted however
is needed.  I don't want to input by hand as there will be several
hundred plots,  in different styles. It needs to have - scatter graphs
(up to 500 points) - mean and standard error to plot error bars - curve
fitting (preferably splines - the data is not polynomial) - overlay
graphs on the same plot in different line formats - some representation
of 3D surfaces such as wire mesh would be nice. - ability to label
points of interest interactively - able to be cut and pasted into a word
3.01 document - compatible with the laser writer.

Any information would be appreciated.  Please mail replies direct to
[e-mail]


------------------------------

From: [e-mail] (Mr. Science)
Subject: PICT files
Date: 13 Oct 87 07:57:09 GMT
Organization: University of California, Berkeley

I am working on an graphics application and wish to be able to read PICT
files (or PICT resources from the clipboard) created by other programs.
I have the relevant TechNotes (#21 on QuickDraw internal format and #27
on MacDraw PICT file format).  However, TechNote #21 states that the
information is for "DEBUGGING PURPOSES ONLY."  The reason being that a
program will not be able to handle "new objects" if they are added at
some future time.

My question is how else can one decipher the information in a PICT file?
Just calling DrawPicture with a handle to the picture will draw the
picture on the screen, but this doesn't help me in extracting the kind
and location of the individual graphics objects.  If a several
rectangles, ovals, and line segments are in the picture, I want to know
the appropriate screen coordinates of each object.  All this info is in
the PICT file, but it does depend on knowing, for example, that hex code
30 is a rectangle, with the next 8 bytes giving the coordinates of the
corners of that rectangle.  Should I just ignore the caveat in the
TechNote and parse the PICT file or is there some other clever way of
extracting the information?  (Anyone know if Apple has, in fact, added
new objects?)

In keeping with recent requests, please e-mail responses to me and I
will summarize them in a later posting.

Thanks in advance.

  Gregory Dow            ARPA:   [e-mail]
  Chemical Engineering Dept.    UUCP:   {uwvax, decvax, ihnp4, ...}!ucbvax
  University of California              !campoly%violet.berkeley.edu
  Berkeley, CA  94720        BITNET: POLYDOW@UCBCMSA


------------------------------

From: [e-mail] (Phil Hunt)
Subject: Mac II fan noise
Date: 13 Oct 87 16:54:00 GMT
Organization: Digital Equipment Corporation

The user manual states that the noise of the fan will INCREASE as the
machine gets hotter..   I find my fan very quiet, quieter than a Jasmine
80 I had, so the noise is acceptable to me.

Phil Hunt


------------------------------

From: [e-mail] (Kerien Fitzpatrick)
Subject: Intermail owners take note/Intermail buyers should read
Date: 13 Oct 87 17:25:36 GMT
Organization: Carnegie-Mellon University, CS/RI

For those of you who own Intermail and don't know it....Internet has
sold Intermail to Microsoft.  I purchased Intermail back in January of
1987 and was told at that time that I would have the ability to create
mailing groups.  Alas, it is October and our mail list does not have
groups so people have to sort through 50 names.  Intermail has been
fairly reliable, but it has numerous shortcomings that keep it from
being considered a mature product.

Pros:
*  Installs as a DA.
*  Somewhat fast.
*  Does not require dedicated server.
*  Works on an AppleShare server with LaserShare running as a concurrent
application.
*  Works with seemingly all applications.

Cons:
*  Can't compress the data file. Our data file frequently grows to 9Mb.
*  If you want to wipe out the data file you will need to reenter every
username and password.
*  Can't print the userlist to aid in reentering names.
*  Messages can be up to 32,000 characters, but you can only print the first
page of the message.
*  Messages that were saved to a file are file type Document.  You must open
MacWrite or Word first then open the file.
*  Tab key switches between fields and cannot produce an actual tab.

I would love to have Inbox, but since they don't site license I would
have to purchase another copy every time a Mac is added to the network.
Maybe Inbox should think about site licensing their product.  What I
liked the most when Internet owned Intermail was that you could talk to
a person that knew more than how to answer a phone.  It takes multiple
calls to Microsoft to obtain any information.

Is there anyone from Inbox out there who will take pity on a distraught
person who, besides his own research work, manages a network of 32 Macs,
a couple file servers, gateway boxes, and on and on.

------------------------------

End of Usenet Mac Digest
************************